Add bounded split application messages - #984
Open
colonelpanic8 wants to merge 3 commits into
Open
Conversation
colonelpanic8
marked this pull request as draft
July 20, 2026 22:49
Contributor
|
Iirc this is also useful to transport state of the keyboard to the peripheral that is not available in the usual split protocol right? Like for example I have a special function in my firmware that moves the mouse pointer a bit automatically when it's active. And I have a display on the peripheral that should display whether it's active. |
HaoboGu
force-pushed
the
feat/rynk
branch
5 times, most recently
from
July 31, 2026 14:10
c09015e to
d2c97ab
Compare
Add an opaque, bounded application payload that firmware can exchange between the split central and peripheral alongside the normal split traffic, without ever taking priority over key events. * `split_app` module: `SplitAppData` (a small, `MaxSize`, postcard length-prefixed payload) plus four statics — `SPLIT_APP_TX` (central -> peripheral), `SPLIT_APP_PERIPH_TX` (peripheral -> central), the symmetric `SPLIT_APP_RX` inbox, and the `SPLIT_APP_LINK` watch that reports split-link state to the application. * Producers use `try_send` only (bounded, drop-on-full) so the split read/write loops never block or get starved by application traffic; key events are always polled first. * The split driver and peripheral drain the application queues as the lowest-priority arm of their outgoing selects and forward received `SplitMessage::Application` payloads into the inbox. * `SPLIT_APP_LINK` is state-based (a `Watch`), so a late-subscribing application still observes the current link state; the `false -> true` edge is a resync trigger. Link-down edges are emitted from a drop guard so they survive async cancellation of the split session. * On the peripheral the link is raised on the FIRST inbound message from the central rather than on bare connection: over BLE, notifications to a central that has not yet subscribed are silently dropped, so the connection alone is not proof the application channel is usable. Developed for a split keyboard port.
colonelpanic8
force-pushed
the
glove80-rmk/split-app
branch
from
August 5, 2026 08:12
6f436cf to
0195a61
Compare
Size Report
|
colonelpanic8
marked this pull request as ready for review
August 5, 2026 08:59
Move the duplicated inline LinkDownGuard structs into split_app as a single LinkGuard that also owns the idempotent link-up edge, extract the peripheral's central-message match into handle_central_message so it is no longer nested five levels deep inside run(), share the drop-on-full inbox delivery between both sides, and trim comments down to the non-obvious facts. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Collaborator
|
what is this message used for? |
Contributor
|
Would be good to have some docs on how to use this. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Why
RMK-based firmware sometimes needs to coordinate application-owned state across halves without adding hardware-specific meaning to the core split protocol. Per-key lighting is one consumer, but this API stays opaque and allocation-free.
Impact
Existing split behavior is unchanged unless the new queues are used. The implementation currently targets a single split peripheral and documents that limitation.
Checks